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ABSTRACT 

In  this  contribution,  we  give  an  overview  on  the  military  multi-agent  simulation  environment  ITSimBw, 
which  is  developed  at  Fraunhofer  IAIS/ART  under  contract  for  the  department  AS  of  the  IT  office  of  the 
German  Armed  Forces  (ITAmtBw),  where  the  project  is  overseen  by  Captain  Thomas  Doll. 

Due  to  the  growing  importance  of  network  centric  capabilities  in  military  operations,  one  of  the  main 
focus  points  for  the  development  of  ITSimBw  is  the  faithful  modelling  of  IT  and  communication  aspects. 
This  goal  is  achieved  essentially  by  two  means: 

1.  A  message  format  for  simulated  communication  acts  between  agents  is  provided  which 
allows  the  detailed  specification  of  communication  channel,  medium,  and  range. 

2.  A  voxel-space  representation  is  used  to  model  the  extension  of  all  objects  belonging  to 
the  simulated  environment.  This  allows  for  the  application  of  high  performance  ray 
tracing  algorithms  to  precisely  determine  the  impact  of  effects  like  radio-pockets  (e.g. 
caused  by  mountains)  as  well  as  jamming  by  opposing  forces. 

These  two  features  in  conjunction  allow  for  a  detailed  and  realistic  modeling  of  communication  chains  for 
reporting  and  command  both  inside  and  across  different  echelons. 

Clearly,  the  modelling  of  communication  aspects  can  only  reasonably  be  carried  out  in  an  environment 
which  is  rich  enough  to  support  the  simulation  of  a  broad  variety  of  scenarios.  ITSimBw  addresses  this 
point  by  strictly  adhering  to  an  agent-oriented  paradigm  which  allows  for  the  specification  of 
autonomous,  situation-based  behaviour  for  all  entities.  This  extended  agent  concept  includes  environment, 
weather,  bridges,  obstacles,  and  the  like  as  active  elements.  This  means  that  all  effects  and  events  are 
handled  as  actions  of  agents. 

Another  important  issue  for  any  simulation  system  is  the  precise  and  comprehensive  description  of  the 
scenarios  which  are  to  be  examined.  To  this  end,  ITSimBw  encompasses  its  own  LAMPS  description 
language.  Being  based  on  high-level  Petri-Nets,  it  can  be  represented  graphically  and  by  rule-sets. 
Moreover,  due  to  its  generality,  it  is  equally  well  suited  for  the  description  of  complete  scenarios  as  for  the 
specification  of  agent  behaviour.  An  important  area  of  ongoing  research  and  development  is  the 
capability  of  LAMPS  to  record  events.  This  feature  enables  the  creation  of  a  scenario  data-base 
containing  mission  graphs  from  simulation  runs  as  well  as  real-world  manoeuvres  or  even  actual  military 
missions.  This  data-base  can  then  form  the  core  component  of  a  decision  support  system  for  the  military 
commander.  Like  a  chess  player  comparing  a  current  board  position  with  memorized  games  to  determine 
the  next  move,  a  graph-metric  can  be  used  to  liken  the  LAMPS  graph  of  an  ongoing  mission  with  those  in 
the  data-base.  We  thus  envisage  LAMPS  to  be  a  core  factor  for  the  application  of  data-mining-techniques 
in  mission  evaluation. 
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1.0  INTRODUCTION 

In  this  contribution,  we  present  the  military  multi-agent  simulation  environment  ITSimBw  and  its 
description  language  LAMPS,  which  is  used  for  the  specification  of  agent  behaviours  as  well  as  complete 
scenarios. 

One  of  the  main  challenges  of  simulations  is  the  optimal  choice  concerning  the  degree  of  model  detail. 
Coarse  models  commonly  yield  very  broad  and  abstract  results  with  little  value  for  the  military 
practitioner.  Overly  detailed  models  on  the  other  hand  produce  outcomes  that  are  too  dependant  on  minute 
situational  details  thus  preventing  their  applicability  to  other  scenarios  even  if  they  are  highly  similar. 
Therefore,  scaling  aspects  play  a  major  role  in  the  design  of  simulation  tools. 

Another  important  issue  for  any  simulation  system  is  the  precise  and  comprehensive  description  of  the 
scenarios  which  are  to  be  examined.  To  this  end,  ITSimBw  [1]  encompasses  its  own  LAMPS  description 
language.  Being  based  on  high-level  Petri-Nets,  it  can  be  represented  graphically  and  by  rule-sets. 
Moreover,  due  to  its  generality,  it  is  equally  well  suited  for  the  description  of  complete  scenarios  as  for  the 
specification  of  agent  behavior. 

In  our  view,  the  unique  combination  of  features  outlined  in  the  preceding  paragraphs  distinguishes 
ITSimBw  from  other  commonly  used  military  simulation  tools  such  as  MANA  [2]  or  Pythagoras  [3]. 

LAMPS  can  be  used  to  document  and  analyze  processes  and  to  directly  implement  corresponding 
simulations.  LAMPS  is  designed  to  have  a  broad  application  scope,  so  that  a  wide  range  of  processes  can 
be  modelled,  including  business  processes,  warfare  scenarios  [1],  critical  infrastructures [4],  or  physical 
simulations.  This  wide  applicability  is  due  to  LAMPS'  generic  approach  which  uses  agents  to  represent  all 
active  entities.  All  entities  in  the  system,  including  environment  objects,  IT-systems,  or  classic  agents,  can 
be  modelled  in  the  same  way  as  agents.  All  effects  and  events  are  modelled  as  actions  of  agents. 

In  the  next  section  we  give  a  broad  overview  of  related  work.  In  Section  3  the  key  concepts  of  ITSimBw, 
which  have  already  been  touched  upon  in  this  introduction,  are  explained  in  more  detail.  Section  4 
describes  the  concept  of  voxelspaces  that  are  used  to  represent  the  spatial  extent  of  agents.  Section  5  then 
gives  an  exposition  of  the  underlying  architecture  and  the  way  communication  is  dealt  with  in  the 
environment,  followed  by  a  presentation  of  the  main  concepts  of  the  LAMPS  description  languageused  for 
simulation  and  decision  support,  in  section  6.  Finally,  section  7  concludes. 


2.0  RELATED  WORK 

While  languages  for  the  specification  of  simulation  models  abound,  LAMPS  is  to  our  knowledge  the  only 
one  that  supports  both  the  description  of  scenarios  and  the  executable  specification  of  agent  behaviour  for 
compound  agent  groups  down  to  individual  agents.  Existing  simulation  models  are  usually  extensions  of 
programming  languages  such  as  C/C++  (e.g.  Maisie  [5]  or  the  SPaDES  environment^])  or  Java  (e.g. 
SILK[7],  the  SSJ  package  [8]).  In  contrast,  LAMPS  is  based  on  high-level  Petri  nets  [9].  Thus,  LAMPS 
inherently  supports  parallel  simulation,  and  is  not  an  extension  of  sequential  simulation  languages  like 
Maisie  or  SIMSCRIPT  III  [10].  Like  other  modern  simulation  languages  [8],  LAMPS  can  be  displayed 
both  graphically  and  as  a  rule-set. 

LAMPS  is  based  on  hierarchical  Petri  Nets  [9]  and  Colored  Petri-Nets  (cf.  [11]).  The  former  introduced 
the  idea  to  structure  so-called  places  (states)  and  actions  hierarchically;  the  latter  introduced  the  idea  of 
typed  tokens.  LAMPS  extends  Petri-nets  by  the  concept  of  agents. 

ITSimBW  extends  classical  agent-based  simulation  [12]  by  rigorously  modelling  all  effects  and  events  as 
actions  of  agents.  Furthermore,  ITSimBw  handles  scheduling  by  grouping  agents  on  to  different 
tagboards.  A  tagboard  handles  all  messages  for  a  group  of  agents. 
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3.0  THE  AGENT  PARADIGM 

In  contrast  to  other  multi-agent  systems,  where  a  few  complex  agents  interact  in  a  feature-rich 
environment,  ITSimBw  is  designed  from  the  ground  up  with  an  agent-oriented  paradigm  in  mind. 
Consequently,  virtually  every  part  of  a  simulation  can  be  modelled  as  an  autonomous  agent.  This  includes 
humans,  software,  the  landscape,  weather  phenomena  like  clouds  or  rain,  and  inanimate  objects  such  as 
bridges  and  other  buildings.  Although  many  of  these  agents  are  usually  passive,  they  can  be  activated  at 
any  time  if  required  by  the  investigated  scenario. 

Since  the  principles  of  autonomous  agents  do  not  allow  manipulating  agents  from  the  outside,  all 
influences  are  communicated  via  messages  to  which  the  receiving  agent  is  free  to  comply.  Each  agent 
consists  of  a  set  of  attributes  and  an  interface.  The  interface  is  used  to  communicate  with  the  other  agents. 
Effects  like  weapon  fire,  weather  influences,  and  the  like,  are  communicated  via  specialized  messages 
which  carry  the  effect  type.  The  concrete  impacts  of  effects,  however,  are  stored  in  a  central  data  structure, 
the  effect  table.  Thus,  the  ITSimBw  user  has  a  single  reference  point  for  changing  the  impact  of  effects 
which  can  be  influenced  by  non-programmers. 


4.0  VOXELSPACE 

Since  scenarios  in  military  operations  are  often  heavily  influenced  by  terrain,  weather,  the  exact  position 
of  all  objects,  etc.,  an  exact  3D  representation  of  all  physical  entities  is  important  for  a  realistic  result  of  a 
military  simulation.  We  use  voxels  to  represent  physical  agents  in  our  environment.  A  voxel  is  a 
portmanteau  of  the  words  volumetric  and  pixel.  Each  voxel  represents  a  regular  volume  of  space.  Contrary 
to  the  commonly  used  approach  we  organize  voxels  inside  an  octree.  Octrees  are  usually  used  to  subdivide 
a  scene  into  elements  (in  this  example  boxes),  so  that  each  element  ideally  contains  one  object  of  the 
scene.  So  in  a  regular  octree,  a  box  is  divided  into  8  equally  sized  subboxes,  which  than  again  can  be 
divided  into  8  subsubboxes  and  so  on. 

Since  we  have  not  a  static  scene,  where  all  objects  stay  in  their  boxes,  we  use  a  voxelspace  for  each 
individual  object.  This  is  also  used  in  modem  computer  games  like  Delta  Force  or  Command  &  Conquer. 
We  use  octrees,  because  insertion  and  deletion  of  objects  are  cheap  (0(1),  if  one  knows  the  size  of  the  new 
object),  there  are  efficient  algorithms  to  intersect  cubes  and  lines  (  the  use  will  be  shown  in  the  next 
section)  ,  and  voxelspaces  can  be  efficiently  used  for  occlusion  culling.  In  addition  each  voxel  may 
contain  additional  attributes  like  density,  weight,  and  so  on.  There  are  also  different  densities  for  different 
effects,  which  may  be  influenced  by  a  voxel,  e.g.  for  radio  transmissions,  vision,  and  physical  density  (if 
one  can  move  through  an  object). 


5.0  THE  FTA  ARCHITECTURE 

5.1  Core  Concepts 

The  ITSimBw  simulation  environment  is  based  on  the  Flip-Tick- Architecture  (FTA)  [13],  which  has  its 
roots  in  the  JANUS  project  developed  at  the  Gesellschaft  fur  Mathematik  und  Datenverarbeitung  (GMD) 
[14].  At  its  core,  FTA  is  a  design  paradigm  for  scalable  distributed  systems  that  exhibit  unknown  dynamic 
characteristics  as  well  as  disturbances  and  inaccuracies  which  are  difficult,  if  not  impossible,  to  model  in  a 
closed-form  mathematical  approach.  As  every  multi-agent  system,  FTA  is  based  on  the  concept  of  a 
society  of  agents  [15].  It  comprises  four  classes  of  entities:  actors  (i.e.  agents),  assemblies,  tags,  and  tag- 
boards. 

The  aforementioned  society  of  agents  A  is  formed  by  a  set  of  individual  agents  aj,  which  are  called  actors 
in  FTA  terminology: 
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A  =  {au...,aj,...ak}.  ^ 

Each  actor  aj  is  composed  of  a  set  of  typed  attributes  Uh  whose  value  assignment  determines  the  agent’s 
state,  together  with  an  action  function,  which  entails  all  operations  that  can  be  performed  by  the  actor. 


Cl  j  (U j  Ohj  v?  Umj  )?  fj  )•  ^2) 

Structural  information  concerning  agents,  i.e.  names  and  types  of  attributes,  is  described  via  agent  types. 
Formally,  we  have  type(aj)  =  t ,  if  and  only  if  agent  aj  is  of  type  t.  The  system  supports  agent  templates 
that  can  be  used  to  store  prototypical  value  assignments.  Thus,  an  individual  agent  can  be  created  either  by 
instantiation  of  its  type,  or  by  copying  from  a  pre-defmed  template. 

The  principle  of  autonomy  of  agents  forbids  the  direct  manipulation  of  internal  data  structures  and 
behaviors  of  other  agents.  Consequently,  all  interactions  between  agents  are  handled  via  messages. 
Formally,  a  message  Nv  is  comprised  of  a  number  of  attributes: 

=  (Ml,v,...«/,v)  (3) 

As  agents,  messages  are  typed  entities.  The  set  of  all  message  types  is  given  by 

iV  =  {iVlv..,iVA}_(4) 

Upon  receiving  a  request,  the  agent  is  able  to  analyze  its  content  and  to  decide  whether  it  wants  to  comply. 
The  basic  unit  of  execution  is  called  a  cycle.  During  one  cycle,  the  agent  reads  its  messages  and  triggers 
the  appropriate  actions,  which  might  consist  of  writing  messages  to  other  actors. 

An  assembly  is  a  set  of  agents  sharing  a  common  pace,  i.e.  all  elements  of  an  assembly  have  the  same  time 
resolution  dt.  This  in  turn  implies  that  their  cycles  are  synchronized  and  that  the  assembly  switches  from 
cycle  to  cycle  as  regularly  as  the  tick  of  a  clock.  Hence  the  term  Tick  in  FTA.  It  is  important  to  note,  that 
different  agents  do  not  necessarily  share  the  same  time  resolution.  Instead,  the  architecture  supports 
individual  running  speeds  for  every  actor.  Moreover,  time  steps  can  vary  from  cycle  to  cycle.  Thus, 
adaptive  control  of  time  increments  can  be  realized  (see  below).  This  is  particularly  valuable  for 
increasing  the  time  resolution  in  the  computation  of  dynamics  equations  for  fast  moving  objects. 

The  messages  used  for  inter-agent  communication  are  called  tags  in  FTA.  We  distinguish  between  three 
different  categories  of  tags: 

•  Message  tags  are  the  carriers  of  communication  between  agents.  Orders  are  embedded  in  message 
tags  using  XML  syntax. 

•  Position  tags  contain  the  current  position  of  agents.  They  are  sent  when  actors  change  their 
position. 

•  Effect  tags  are  used  to  mediate  effects  like  weather  influences,  weapon  impact,  and  the  like. 

Instead  of  setting  up  a  direct  communication  with  other  actors,  agents  register  with  one  ore  more  tag- 
boards,  to  which  they  send  their  messages.  Thus,  tag-boards  serve  as  the  functional  units  for  handling 
messages  in  the  FTA  system.  In  formal  terms,  a  tag-board  forms  a  medium  Mn  for  message  exchange, 
while  a  FTA  system  is  capable  of  supporting  multiple  media: 

M  =  {mx  }. 
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A  tag-board  consists  of  two  sides.  One  is  write-only  and  contains  all  tags  sent  to  the  board  in  time  step  t , 
whereas  the  other  side  is  read-only  and  encompasses  all  tags  written  in  time-step  t- 1.  Analogously  to 
agents,  each  tag-board  has  its  own  time  resolution  and  thus  its  own  cycle  time.  During  a  board  cycle,  the 
write-only  side  is  flipped  over.  Thereby,  the  read-only  part  mirrors  the  tag  content  of  the  write  part  from 
the  previous  time-step.  The  write-only  side  is  deleted  after  flipping.  In  this  way,  the  lifetime  of  tags  is 
effectively  controlled  by  the  time-scale  of  the  pertaining  board.  These  interrelations  are  depicted 
graphically  in  figure  2. 

With  this  approach,  fully  synchronized  (all  agents  and  tag-boards  share  the  same  time  resolution)  as  well 
as  completely  asynchronous  systems  (every  agent  and  every  board  has  its  own  time-scale)  can  be  modeled 
in  terms  of  the  FTA. 


Time 


t+ 


t+ 


Figure  1 :  Inter-agent  communication  via  tag-board. 


The  mathematical  model  of  this  agent  architecture  is  a  system  of  flexibly  coupled  inhomogeneous 
difference  equations 


D  -  (Du...,Dk), 

where  each  agent  computes  an  equation  from  D.  In  this  setting,  the  attribute  list  of  an  actor  corresponds  to 
the  variable  vector  of  the  pertaining  difference  equation.  Thus,  equation  Dt  of  agent  aL  computes 

U‘+d,t  =fi(U‘),  (7) 

where  dti  denotes  the  time  step  size  of  agent  ai.  During  the  iteration  of  D,  the  society  of  agents  runs 
through  a  set  of  states  Z  =  {Z1},  where  each  of  these  system  states  is  the  union  of  attribute  sets  from  all 
participating  agents: 

(£//,-, uU^ui).  (8) 
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Since  the  Dt  are  computed  using  potentially  different  dtt ,  the  involved  agent  attribute  sets  lf\  might  be 
undefined  for  certain  t.  In  this  case,  either  the  U]  from  the  last  time  step  of  D{  is  used,  or  U]  is  explicitly 
recomputed.  We  thus  have 

_  y  0  yti  ytj  rye 

—  Z-j  j  •  •  •  y  Z-j  Zi  ^ ...  ^  Zu 

k 

tj-h  =Mindtk ■ 
where  h=l  (9) 

A  graphical  visualization  of  FTA  (omitting  the  discrimination  of  different  tag-board  sides)  is  shown  in 
figure  3 : 


Agent 


Figure  2:  The  Flip-Tick-Architecture.  Arrows  denote  read()  and  write()  operations.  The  colors  specify  types  of 
agents  and  tags.  It  is  depicted  that  agents  can  subscribe  to  more  than  one  tag-board. 

5.2  Communication 

Although  ITSimBw  does  not  force  its  users  to  model  IT  and  communication  equipment  as  individual 
agents,  this  procedure  is  highly  encouraged  by  the  pervasive  agent-based  modeling  paradigm. 

The  simulation  system  supports  communication  modeling  essentially  by  two  means: 

•  A  message  format  for  simulated  communication  acts  between  agents  is  provided  which  allows  the 
detailed  specification  of  communication  channel,  medium,  and  range. 

•  The  voxel-space  mentioned  in  the  previous  subsection  is  used  to  determine  environmental  effects 
on  communication,  e.g.  mountains  causing  radio  pockets,  as  well  as  jamming  by  opposing  forces. 

These  two  features  in  conjunction  allow  for  a  detailed  and  realistic  modeling  of  communication  chains 
both  inside  and  across  different  echelons. 


Figure  3:  The  model  of  a  Message  send  from  Sender  to  Receiver  through  a  Voxelspace 
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6.0  LAMPS 

6.1  Basic  Constructs 

LAMPS  uses  the  following  concepts  from  hierarchical  and  coloured  Petri  nets: 

•  Places  hold  states,  i.e.  in  LAMPSSys  they  contain  subsets  of  the  agent  attributes.  The  content  of  a 
place  is  called  token  and  can  be  of  an  arbitrarily  complex  structured  type.  Places  can  contain  several 
tokens  of  different  or  identical  types. 

•  Actions  describe  the  effects  that  agents  apply  to  themselves  or  to  other  agents. 

•  Relations  denote  the  links  between  places,  actions,  and  agents.  Relations  correspond  to  the  arcs  in 
the  Petri  net  model. 

LAMPS  introduces  the  additional  concept  of  agents  in  the  following  way: 

•  Agents  correspond  to  the  conditions  of  Petri  nets.  An  agent  in  LAMPS  observes  the  set  of  places 
that  have  relations  to  the  agent's  actions.  Based  on  these  places  the  agent  decides  which  actions  are 
executed  and  which  parameters  should  be  used. 

Agents  extend  guard  functions  (Esser  1997)  and  enabling  functions  (Schoef  1995).  These  serve  as 
preconditions  that  are  checked  before  an  action  is  executed.  Figure  4  depicts  a  simple  example  using  the 
four  basic  concepts. 


Resistance 

broken 


Figure  4:  A  LAMPS  fragment  using  the  four  basic  concepts.  The  agent  Inf  A  observes  the  place 
Enemy  spotted.  If  the  place  contains  a  token,  the  agent  executes  action  Combat,  which  sends  a 

token  into  the  place  Resistance  broken. 

LAMPS  is  inherently  parallel  due  to  its  core  of  high-level  Petri  nets.  Agents  live  in  parallel,  and  each 
agent  can  execute  several  parallel  actions.  All  actions  whose  conditions  are  true  in  a  given  cycle  are 
executed.  This  is  also  the  main  difference  to  flow-charts,  because  there  are  several  tokens  per  place,  and 
several  places  can  be  filled  simultaneously. 

All  basic  constructs  can  be  recursively  encapsulated.  For  example,  places  can  be  combined  to  so-called 
superplaces.  An  action  can  be  recursively  defined  as  a  LAMPS  process  (with  places  and  other  actions),  as 
long  as  the  interface  (i.  e.  the  incoming  and  outgoing  places)  of  the  action  and  the  process  are  identical. 
This  way,  a  process  can  be  modelled  and  viewed  on  different  detail  levels. 

Since  LAMPS  introduced  agents,  also  agents  can  be  recursively  encapsulated.  A  group  of  agents  can  be 
aggregated  into  an  agent  (say,  a  group  of  soldiers  into  an  infantry  unit).  The  level  of  detail  can  be 
modulated  even  at  runtime  (see  section  below). 
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6.2  Features 

While  LAMPS  is  not  restricted  to  a  time  model,  LAMPSSys  is  discrete-time  and  thus  discrete-event. 

Time-modelling  is  not  trivial  in  high-level  Petri-nets  (cf.  [11]).  Thus,  in  the  LAMPSSys  framework  the 
execution  is  cycle-based  with  a  global  clock.  In  each  cycle  all  agents  can  execute  one  or  more  actions. 
Long  actions  are  modelled  as  a  series  of  consecutive  actions  of  duration  dt.  Synchronisation  is  achieved 
via  places  and  conditions. 

In  the  approach,  time  scaling  is  possible.  In  each  cycle,  each  agent  proposes  a  duration  for  its  action.  The 
simulation  engine  selects  the  minimum  of  the  proposed  durations  and  sets  dt  accordingly.  To  illustrate 
this,  assume  that  an  agent  is  about  to  execute  an  action  that  needs  a  coarse  granularity.  This  could  be  for 
example  an  action  that  moves  a  soldier  from  one  position  to  a  distant  position,  proposing  dt  =  5 min. 
Assume  that  another  agent  is  about  to  execute  a  more  detailled  action  in  the  time-cycle,  for  example, 
shooting  at  an  enemy,  proposing  dt  =  0.01  sec.  In  this  case,  the  simulation  will  set  the  general  dt  to  0.01  sec, 
so  that  every  action  in  this  time  cycle  is  executed  in  this  granularity. 

6.3  Graph-Metric 

In  a  simulation  the  time  is  run  in  disc  cycles.  Time  is  therefore  a  series’  of  timestamps: 
tx^t2^>  ...  ->  tm 


A  state  S  in  a  point  in  time  t  is  described  by  the  states  of  all  the  individual  agents  si  to  sn. 


Figure  5:  The  state  of  each  agent  is  transformed  from  Time  t  ->  t’  by  actions  performed  on  these 

states. 


12-8 


RTO-MP-MSG-045 


^INATO 

W\vrm 


The  ITSIMBW  Environment  for  Simulation  and  Decision  Support 


A  simulation  run  is  fully  described  by  the  set  of  all  states  S  in  all  time  steps  t.  Repeatedly  running  a 
simulation  with  varying  parameters  leads  to  a  set  of  results: 

R  =  {rl,r2,...,rh} 

Our  target  is  to  find  out  typical  situations  over  several  runs.  Since  all  states  of  all  agents  in  all  time  steps 
result  in  an  overwhelming  amount  of  information,  certain  attributes  that  are  considered  relevant  are  chosen 
beforehand.  For  military  simulations  these  are  usually: 

The  position  (in  the  3D  space) 

The  loss  of  own  troops 

The  time  to  accomplish  the  mission  goal 

The  amount  of  effects  to  act  upon  the  opponent 

With  these  four  constraints  and  the  time  at  which  a  certain  state  is  reached,  we  then  build  equivalence 
classes  over  different  runs.  This  can  be  accomplished  by  k-means  clustering. 


s, 


With  these  generated  clusters  we  can  build  a  Markov  chain  that  has  the  probability  that  a  certain  state  can 
be  reached  from  the  actual  state  out  of  the  cluster. 
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Figure  7:  Markov  chain  describing  the  probabilities  of  transformation 


7.0  CONCLUSION 

In  this  paper  we  have  given  a  broad  overview  over  our  architecture.  We  have  shown  the  basics  of 
LampsSys  and  how  we  gain  information  about  our  simulated  task  by  multistarting  our  simulation  and  then 
cluster  over  the  resulting  runs. 
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Outline 


►  Features  of  ITSimBW 

►  Scalability 

►  Focus  on  Cummunication 

►  Freedom  of  modelling 

►  Viewing  alternatives  graphically  (decisions  and/or  events) 

►  Basic  principles  of  technical  realization 

►  Language  for  Agent-based  Modelling  of  Processes  and 
Scenarios  (LAMPS) 

►  Graph  Metrics 

►  Roadmap  for  the  next  steps  (Gis,  HLA  ...) 


2006 


Scalability  Multi-Scale  Approach 


Strategic  level 


■  Global  view 

■  Mission  troups  act  as  one  single  agent 

■  Time  scale  1  minute 


Tactical  level 


■  Local  effects  are  modeled 

■  More  detailed  agents 

■  Time  scale  1  second 
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Scalability  Multi-Scale  Approach 


►  Scalable  complexity: 

■  functionality  (how  detailed  are  functions/effects  modeled/simulated  ?) 

■  time  (in  which  time  steps  will  the  simulation  proceed  ?) 

■  space  (which  spacial  scale  will  be  chosen  for  modeling? 


►  changable  during  run  time 

►  at  different  places  different  changes  possible 

►  system  can  be  built  in  several  stages  (also  depending  on  modeling  efforts) 

►  Granularity  in  modeling  should  be  further  refined  only  if  it  makes  sense 
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■  A  simulation  model  must  be  adjustable  to  the  appropriate  scope 
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This  scope  is  changing  from  task  to  task 


LAMPS 


►  Language  for  Agent  based  Modelling  of  Processes  and  Scenarios 

►  Based  on  high-level  Petri-Nets 

►  Actions  describe  the  effects  that  agents  apply  to  themselves  or  to  other  agents 

►  Relations  denote  the  links  between  places,  actions,  and  agents. 

►  Agents  correspond  to  the  conditions  of  Petri  nets 

►  Graphical  and  textual  representation 

►  Not  restricted  to  a  timing  model 

►  Time  scaling  is  possible 
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LAMPS 
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Enemy  spotted 


Combat 


Resistance 

broken 
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Agent  Architecture  fta 


Agent 


Agents  carry  out  the  system  processes 


What  are  the  active  system  components  ? 


Autonomous  active  elements 

►  Persons 

►  Machines,  vehicles 

►  Objects,  Bridges,  ... 

►  ... 
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Agent  Architecture  fta 


Agent 


Agents  cause  effects  by  producing  tags 


How  do  active  elements  interact  ? 


Causing  effects 

►  spoken  messages 

►  physical  interaction 

►  effects  of  weapons 

►  ... 
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Agent  Architecture  fta 


Agent 


How  do  active  elements  interact  ? 


Taking  effects 

►  reading  a  message 

►  realizing  physical  effects 

►  taking  orders 

►  ... 


Agents  are  self-responsible  for  their  own  behavior,  there  is  no  direct  action  from  outside 
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Agent  Architecture  fta 


How  do  active  elements  understand  each  other  ? 


Agent 


Tags  have  a  type 

►  order  form 

►  general  message 

►  physical  power  (effects) 

►  ... 


Tag  types  describe  the  form,  tag  instances  contain  the  concrete  data 
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What  is  the  radius  of  an  interactionen  ? 


Agent 


Tag  Board 


d  dr 


Regions  of  local  interaction 

►  rooms,  streets 

►  radius  of  physical  effects 

►  communication  links 

►  ... 


Tag  boards  serve  as  models  for  regions  of  interaction 
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Agent  Architecture  fta 


What  is  the  system‘s  topology  ? 


Agent 


Tag  Board 


d  dr 


I iAt 


Agents  can  link  together  several  regions  of  local  interaction 
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Agent  Architecture  fta 


What  is  the  system‘s  topology  ? 


Real  topologies  can  be  modeled  1:1 


Modelling 


Environment 


landscape  model 


►  3D  voxel  model  for  environment 
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Modelling  Environment  +  Communication 


►  computationally  fast 

►  scalable  in  resolution 

►  appropriate  for  multi-scale  features 


►  3D  voxel  model  for  environment 


►  obstruction  of  radio  communication 

►  electronic  countermeasures 

►  weather,  clouds,  mist,  smoke 

►  visibility 

►  shapes  of  units 

►  ... 
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„To  know  what  might  happen" 


Modes  of  use  Combat  Support 
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Szenario  Description 


Szenario  Data  Base 


ITSim 


Combat  Support 


►  C4I  with  szenario  data 
base 

►  more  coherent  behavior 

►  „no  improvisation 
needed" 
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Modes  of  use  Combat  Support 


1. 


O) 

c 


E 


< 


ro 

C3 

o 


2. 
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Multi-scale  simulation  of  scenarios 

■  environment 

■  communication 

■  reporting  structures 

■  order  structures 

■  effects 


Analysis  of  variables 

■  communication  load 

■  risk  measured 

■  probabilities  of  failure 


Scenario  analysis 

■  alternative  scenarios 

■  critical  paths 

■  demands,  costs,  ... 

■  time-dependent  factors 

■  operation  orders,  bill  of  materials 

■  training  maneuvers 


scenario 

database 


Online-C2System  (decision  support) 
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comparison  between  stored  and  current  mission  graph  based  on  similarity  measures. 


Outlook 


►  Scalable  in  space,  and  functionality 

►  Finishing  the  LAMPSSys-Core 

►  Finishing  of  the  HLA-Impementation 

►  Adapter  for  statistical  Analysis  and  GIS 
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Graph-Metric 


►  In  a  simulation  the  time  is  run  in  disc  cycles 

tx^t2^ ...  — >  tm 

►  A  state  S  in  a  point  in  time  t  is  described  by  the  states  of  all  the 
individual  agents 

St  — {s^ ,  s2  ,•••?  $n } 

►  A  simulation  run  is  fully  described  by  the  set  of  all  states  S  in  all 
time  steps 

R  =  {rl,r2,...,rh} 
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Graph-Metric 
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Graph-Metric 


►  For  all  attributes  of  all  agents  in  all  time  steps  this  is  an 
overwhelming  amount  of  information 

►  =>  we  pick  interesting  attributes  beforehand: 

►  The  position  (in  the  3D  space) 

►  The  loss  of  own  troops 

►  The  time  to  accomplish  the  mission  goal 

►  The  amount  of  effects  to  act  upon  the  opponent 
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Graph-Metric 


Markov  tree  with 
propabilities  at  the  edges 


Clusters  over  time  and  runs 
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Technical  Realization  Agent  Technology 


►  The  world  consists  of  concurrent  interacting  agents 
(also  non-human  parts  of  the  game  are  modeled  as 
agents) 

►  The  real-world  behavior  is  simulated  in  detail  on  a 
computer  as  an  artificial  reality 

►  Humans  and  real  systems  outside  the  simulator  are 
coupled  with  this 

artificial  reality  by  special  communication  agents 
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